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(54) Data communication system, data communication method, data communication apparatus 
and digital interface 



(57) There is disclosed a communication system 
and communication protocol in which a source node and 
one or more destination nodes are logically connected, 
and a connection ID for identifying the logical connection 
relationship is used to control data communication be- 
tween the nodes. There is also disclosed an efficient 
communication system and communication protocol in 
which an optimum time interval between a time to trans- 



mit an i-th (i being an optional integer) data and a time 
to transmit an (i+1 )-th data can be set. There is further 
disclosed a communication system and communication 
protocol in which when the i-th data is not normally re- 
ceived, retry is inhibited only for a predetermined time 
to prevent the retry Irom unnecessarily occurring be- 
tween a destination node slow in receiving process and 
a source node fast in transmitting process. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] The present invention relates to a data com- 
munication system, data communication method, data 
communication apparatus and digital interface, particu- 
larly to a network in which information data (including 
image data) and command data are mixed to perform 
communication at high speed and a communication pro- 
tocol applicable to the network. 

Related Background Art 

[0002] Hard discs and printers have heretofore had 
highest frequencies of use among peripheral apparatus- 
es of personal computers (hereinafter referred to as 
PC). These peripheral apparatuses are connected to 
PC via dedicated input/output interfaces, SCSI (small 
computer system interfaces) or other general-purpose 
digital interfaces. 

[0003] On the other hand, in recent years, digital cam- 
eras, digital video cameras and other AV (Audio/Visual) 
apparatuses have gained public attention as PC periph- 
eral apparatuses. The AV apparatuses are also con- 
nected to PC via dedicated interfaces. 
[0004] Fig. 1 is a view showing a conventional com- 
munication system constituted of PC and AV apparatus. 
[0005] In Fig. 1, numeral 101 denotes an AV appara- 
tus or digital camera, 1 02 denotes PC, and 1 03 denotes 
a printer. 

[0006] The digital camera 101 comprises a memory 
104 in which a photographed image is compressed and 
recorded; a decoding unit 105 for expanding and decod- 
ing the compressed image data recorded in the memory 
1 04; an image processing unit 106; aD/A converter 1 07; 
a display 108 comprising EVF; and a dedicated digital 
I/O unit 109 for connecting the digital camera 101 and 
the PC 102. 

[0007] The PC 102 comprises a dedicated digital I/O 
unit 1 1 0 for connecting the PC 1 02 and the digital cam- 
era 101; an operation unit 111 comprising a keyboard, 
a mouse and the like; a decoding unit 1 1 2 for expanding 
and decoding the compressed image data; a display 
113; a hard disc 114; RAM or another memory 115; an 
MPU 1 1 6; a PCI bus 1 1 7; and an SCSI interface 1 1 8 for 
connecting the PC 102 and the printer 103. 
[0008] The printer 103 comprises an SCSI interface 
119 for connecting the printer 103 and PC 102; a mem- 
ory 120; a printer head 121; a printer controller 122 for 
controlling operation of the printer 103; and a driver 1 23. 
[0009] In the conventional communication system, 
since the digital interface or digital I/O unit 109 of the 
digital camera 101 is not compatible with the digital in- 
terface or SCSI interface 110 of the printer 103, they 
cannot be directly interconnected. For example, a still 



image needs to be transmitted to the printer 103 from 
the digital camera 101 necessarily via the PC. 
[0010] Moreover, in the conventional dedicated inter- 
face or the SCSI interface, when a large volume of data 
5 such as still images or moving images held by the AV 
apparatus are handled, many problems are caused that 
a data transfer rate is low, communication cable for par- 
allel communication is thick, there are only a little 
number of types of connectable peripheral apparatuses, 
'0 connection system is limited and that real-time data 
transfer cannot be performed. 
[0011] Known as one of next-generation high-speed 
high-performance digital interfaces to solve the prob- 
lems is an IEEE (The Institute of Electrical and Electron- 
's ics Engineers, Inc.) 1394-1995 standards. 

[0012] A digital interface conforming to the IEEE 
1394-1995 standards (hereinafter referred to as the 
1394 interface) has following characteristics: 

20 (1 ) data transfer rate is high; 

(2) real-time data transfer system (i.e., Isochronous 
transfer system) and Asychronous transfer system 
are supported; 

(3) connection structure (topology) with a high de- 
2S gree of freedom can be constructed; and 

(4) plug-and-play function and hot-line plug/unplug 
function are supported. 

[0013] In the IEEE 1394-1995 standards, although a 

so physical, electric structure of a connector, two basic data 
transfer systems, and the like are defined, it is not de- 
fined what type of data is transmitted/received based on 
what communication protocol in what data format. 
[0014] Moreover, in Isochronous transfer system of 

35 the IEEE 1394-1995 standards, since a response to a 
sending packet is not defined, there is no guarantee that 
each Isochronous packet is surely received. Therefore, 
when a plurality of continuous data are to be securely 
transferred, or when one file data is segmented into a 

to plurality of data to be securely transferred, Isochronous 
transfer system cannot be used. 
[0015] Furthermore, in Isochronous transfer system 
of the IEEE 1394-1995 standards, even when there is 
a vacancy in a transfer band, the total number of com- 

45 munications is limited to 64. Therefore, when a large 
number of communications are performed in a little 
transfer band, Isochronous transfer system cannot be 
used. 

[0016] Additionally, inthelEEE1394-1995standards, 
so if bus rest occurs in response to the turning ON/OFF of 
a node power supply, the connection/disconnection of a 
node, or the like, data transfer has to be interrupted. In 
the IEEE 1394-1 995 standards, however, when the data 
transfer is interrupted by the bus reset or an error at the 
ss time of transmission, it cannot be known what content 
of data is lost. Furthermore, in order to return once in- 
terrupted transfer, a very intricate communication pro- 
cedure needs to be carried out. 
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[001 7] Here, the bus reset indicates a function ot au- 
tomatically performing the recognition of a new topology 
and the setting of an address (node ID) allotted to each 
node. Therefore, the plug-and-play function and the not- 
line plug/unplug function can be provided in the IEEE 
1394-1995 standards. 

[0018] Moreover, in the communication system con- 
forming to the IEEE 1394-1995 standards, a communi- 
cation protocol has not been concretely proposed for 
segmenting into one or more segment data and contin- 
uously transferring a relatively large amount of object 
data (e.g., still image data, graphic data, text data, file 
data, program data, and the like) which are required 
have no real time properties but have reliability. 
[0019] Furthermore, in the communication system 
conforming to the IEEE 1394-1995 standards, a com- 
munication protocol has not been either concretely pro- 
posed for realizing data communication among a plural- 
ity of apparatuses using a communication system in 
which data is asynchronously broadcast. 

SUMMARY OF THE INVENTION 

[0020] An object of the present invention is to solve 
the aforementioned problems. 
[0021] Another object of the invention is to provide a 
technique in which object data requiring no real-time 
properties can continuously and securely be transferred 
in a data communication system, data communication 
method, data communication apparatus and digital in- 
terface. 

[0022] Further object of the invention is to provide a 
technique in which a time interval between continuously 
transferred data can be optimized in a data communi- 
cation system, data communication method, data com- 
munication apparatus and digital interface, and unnec- 
essary interruption in a series of data transfer can easily, 
securely and efficiently be prevented. 
[0023] Still further object of the invention is to provide 
a technique which can realize an efficient data commu- 
nication in such a manner that unnecessarily occurring 
retry can easily and securely be prevented in a data 
communication system, data communication method, 
data communication apparatus and digital interface. 
[0024] As a preferred embodiment for such objects, 
the present invention discloses a data communication 
system comprising: a source node for performing asyn- 
chronous communication at least once to transfer data 
comprising one or more segments; one or more desti- 
nation nodes for receiving the data transferred from the 
source node; and a controller for setting a logical con- 
nection relationship between the source node and the 
one or more destinatbn nodes, wherein at least one of 
the source node and the controller controls a timing for 
performing the asynchronous communication. 
[0025] As another preferred embodiment, the present 
invention discloses a data communication system com- 
prising; a source node for performing broadcast com- 
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munication at least once to transfer data comprising one 
or more segments based on a logical connection rela- 
tionship; and one or more destination nodes for receiv- 
ing the data transferred from the source node based on 
s the logical connection relationship, wherein the source 
node controls a timing for performing the broadcast 
communication. 

[0026] As another preferred embodiment, the present 
invention discloses a data communication method com- 

10 prising steps of: setting a logical connection relationship 
between a source node and one or more destination 
nodes; performing asynchronous communication at 
least once to transfer data comprising one or more seg- 
ments to the one or more destination nodes; controlling 

»s a timing for performing the asynchronous communica- 
tion; and using the logical connection relationship to re- 
ceive the data transferred using the asynchronous com- 
munication. 

[0027] As another preferred embodiment, the present 

20 invention discloses a data communication method com- 
prising steps of: performing broadcast communication 
at least once to transfer data comprising one or more 
segments to one or more destination nodes based on a 
logical connection relationship; controlling a timing for 

2S performing the broadcast communication; and receiving 
the data transferred from the source node based on the 
logical connection relationship. 
[0028] As another preferred embodiment, the present 
invention discloses a data communication method com- 

30 prising steps of: packetizing data comprising one or 
more segments into a plurality of communication pack- 
ets; and successively transferring the communication 
packets based on a logical connection relationship set 
with one or more destination nodes, the communication 

35 packets being asynchronously transferred after a pre- 
determined time elapses. 

[0029] As another preferred embodiment, the present 
invention discloses a data communication method com- 
prising steps of: receiving communication packets suc- 
40 cessively transferred from a source node based on a 
logical connection relationship set with the source node, 
the communication packets being asynchronously 
transferred after a predetermined time elapses; and 
writing data included in the communication packets into 
45 a memory space common to other apparatuses. 

[0030] As another preferred embodiment, the present 
invention discloses a data communication method com- 
prising steps of: setting a logical connection relationship 
between a source node and one or more destination 
so nodes; notifying the source node and the one or more 
destination nodes of a connection ID for identifying the 
logical connection relationship: and setting in the source 
node a time interval of communication packets succes- 
sively transferred based on the logical connection rela- 
ys tionship. 

[0031] As another preferred embodiment, the present 
invention discloses a data communication apparatus 
comprising; a unit for packetizing data comprising one 
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or more segments into a plurality of communication 
packets; and a unit for successively transferring the 
communication packets based on a logical connection 
relationship set with one or more destination nodes, 
wherein the communication packets are asynchronous- 
ly transferred after a predetermined time elapses. 
[0032] As another preferred embodiment, the present 
invention discloses a data communication apparatus 
comprising: a unit for receiving communication packets 
successively transferred from a source node based on 
a logical connection relationship set with the source 
node; and a unit for writing data included in the commu- 
nication packets into a memory space common to other 
apparatuses, wherein the communication packets are 
asynchronously transferred after a predetermined time 
elapses. 

[0033] As another preferred embodiment, the present 
invention discloses a data communication apparatus 
comprising: a unit for setting a logical connection rela- 
tionship between a source node and one or more des- 
tination nodes and for setting in the source node a time 
interval of communication packets successively trans- 
ferred based on the logical connection relationship; and 
a unit for notifying the source node and the one or more 
destination nodes of a connection ID for identifying the 
logical connection relationship. 
[0034] As another preferred embodiment, the present 
invention discloses a digital interface comprising: a unit 
for packetizing data comprising one or more segments 
into a plurality of communication packets; and a unit for 
successively transferring the communication packets 
based on a logical connection relationship set with one 
or more destination nodes, wherein the communication 
packets are asynchronously transferred after a prede- 
termined time elapses. 

[0035] As another preferred embodiment, the present 
invention discloses a digital interface comprising: a unit 
for receiving communication packets successively 
transferred from a source node based on a logical con- 
nection relationship set with the source node; and a unit 
for writing data included in the communication packets 
into a memory space common to other apparatuses, 
wherein the communication packets are asynchronous- 
ly transferred after a predetermined time elapses. 
[0036] As still further preferred embodiment, the 
present invention discloses a digital interface compris- 
ing: a unit for setting a logical connection relationship 
between a source node and one or more destination 
nodes and for setting in the source node a time interval 
of communication packets successively transferred 
based on the logical connection relationship; and a unit 
for notifying the source node and the one or more des- 
tination nodes of a connection ID for identifying the log- 
ical connection relationship. 

[0037] Still other objects of the present invention, and 
the advantages thereof, will become fully apparent from 
the following detailed description of the embodiments. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0038] Fig. 1 is an explanatory view of a conventional 
system. 

5 [0039] Fig. 2 is a block diagram showing an example 
of a communication system structure of the embodi- 
ment. 

[0040] Fig. 3 is a schematic view showing a basic 
structure of communication protocol of the embodiment. 

10 [0041] Figs. 4A, 4B and 4C are sequence charts 
showing a basic communication procedure of the com- 
munication protocol of a first embodiment. 
[0042] Fig. 5 is a view showing a structure of Asyn- 
chronous broadcast packet of the first embodiment. 

is [0043] Figs. 6A and 6B are explanatory views show- 
ing an address space of each node. 
[0044] Fig. 7 is an explanatory view showing a trans- 
fer model of object data. 

[0045] Fig. 8 is an explanatory view showing a struc- 
20 ture of 1 394 interface of the embodiment. 

[0046] Fig. 9 is a sequence chart showing a response 
period defined in the first embodiment. 
[0047] Fig. 10 is a state transition view showing an 
example of single-phase retry operation defined in a 
25 second embodiment. 

[0048] Fig. 1 1 is a state transition view showing an ex- 
ample of dual-phase retry operation defined in the sec- 
ond embodiment. 

[0049] Fig. 12 is a sequence chart showing a basic 
30 communication procedure of communication protocol of 
the second embodiment. 

[0050] Fig. 13 is a view showing an Asynchronous 

broadcast packet of the second embodiment. 

[0051] Fig. 14 is a view showing a structure of an ac- 
35 knowledge packet defined in the second embodiment. 

[0052] Fig. 1 5 is a view showing operation for setting 

a minimum retry period of the embodiment. 

[0053] Fig. 16 is a view showing types of retry codes 

of the embodiment. 
40 [0054] Fig. 17 is a view showing types of ack codes 

of the embodiment. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

45 

[0055] The preferred embodiments of the present in- 
vention will now be descried in detail hereinafter with 
reference to the accompanying drawings. 
[0056] Fig. 2 is a view showing an example of a data 

so communication system structure in the embodiment. As 
shown in Fig. 2, the data communication system of the 
embodiment is constituted of a computer 10, a digital 
video camera recorder 28, and a printer 60. 
[0057] A structure of the computer 1 0 will first be de- 

55 scribed. Numeral 12 denotes a microprocessor unit 
(MPU) for controlling operation of the computer 10. Nu- 
meral 1 4 denotes 1 394 interface having a function con- 
forming to I EEE 1 394-1 995 standards and a function re- 
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garding a communication protocol defined in the em- 
bodiment. Numeral 1 6 denotes an operation unit consti- 
tuted ot a keyboard, a mouse, and the like. Numeral 18 
denotes a decoder for decoding compressed/encoded 
digital data (moving image data, still image data, audio 
data, and the like). Numeral 20 denotes a display con- 
stituted of a CRT display, liquid crystal panel or another 
display device. Numeral 22 denotes a hard disc (HD) for 
recording various digital data (moving image data, still 
image data, audio data, graphic data, text data, program 
data, and the like). Numeral 24 denotes an internal 
memory. Numeral 26 denotes a PCI bus or internal bus 
for interconnecting processing units inside the computer 
10. 

[0058] A structure of the digital video camera recorder 
(hereinafter referred to as DVCR) 28 will next be de- 
scribed. Numeral 30 denotes an image pickup unit (opt) 
for converting an optical image of an object into an elec- 
tric signal. Numeral 32 denotes an analog-digital (A/D) 
converter. Numeral 34 denotes a video processing unit 
for converting a digitized moving image or a still image 
to a digital image data of a predetermined format. Nu- 
meral 36 denotes a compression/expansion unit having 
a function of decoding compressed/encoded digital data 
(moving image data, still image data, audio data, and 
the like) and a function of encoding digital image data 
with high efficiency (e.g., the data is orthogonally con- 
verted to a predetermined image unit, quantized, and 
encoded with variable length like in MPEG or DV sys- 
tem). Numeral 38 denotes a memory for temporarily 
storing the highly efficiently encoded digital image data. 
Numeral 40 denotes a memory for temporarily storing 
the digital image data not subjected to the highly efficient 
encoding. Numeral 42 denotes a data selector. Numeral 
44 denotes 1 394 interface having the function conform- 
ing to the IEEE 1394-1995 standards and the function 
regarding the communication protocol defined in the 
embodiment. Numerals 46, 48 denote memory control 
units for controlling the writing and reading of the mem- 
ories 38 and 40. Numeral 50 denotes a system controller 
for controlling operation of DVCR 28, which has a mi- 
crocomputer. Numeral 52 denotes an operation unit 
comprising a remote controller, operation panel, and the 
like. Numeral 54 denotes an electronic view finer (EVF). 
Numeral 56 denotes a D/A converter. Numeral 58 de- 
notes a recorder/reproducer provided with a magnetic 
tape, magnetic disc, magnetic optical disc, or another 
recording medium for recording/reproducing various 
digital data (moving image data, still image data, audio 
data, and the like). 

[0059] A structure of the printer 60 will next be de- 
scribed. The printer 60 comprises 1 394 interface 62 
having the function conforming to the IEEE 1 394-1995 
standards and the function regarding the communica- 
tion protocol defined in the embodiment; a data selector 
64; an operation unit 66 constituted of operation buttons, 
a touch panel, and the like; a printer controller 68 for 
controlling operation of the printer 60; a decoder 70; an 



internal memory 72; an image processing unit 74 for 
processing still image data, text data, graphic data and 
the like received via the 1 394 interface; a driver 76; and 
a printer head 78. 

5 [0060] As shown in Fig. 2, for each communication 
apparatus (hereinafter referred to the node), the com- 
puter 10, the DVCR 28 and the printer 60 are intercon- 
nected via the 1394 interfaces 14, 44, 62 (a network 
comprising the 1394 interface will hereinafter be re- 

io ferred to as the 1 394 serial bus). In each node, various 
object data (e.g., moving image data, still image data, 
audio data, graphic data, text data, program data, and 
the like) can be transmitted/received, and remote oper- 
ation can be realized using command data by defining 

<5 the predetermined communication protocol. In the em- 
bodiment, the communication protocol using Asynchro- 
nous transfer system is defined. 
[0061] Operation of the nodes constituting the com- 
munication system of the embodiment will next be de- 

20 scribed with reference to Fig. 2. 

[0062] First, the function and operation of the 
processing units constituting the computer 10 will be de- 
scribed. 

[0063] In the embodiment, the computer 10 serves as 
25 a controller for controlling transmission/reception of im- 
age data between DVCR 28 and printer 60, or a control- 
ler for remotely operating DVCR 28 and printer 60. 
[0064] The MPU 1 2 executes software recorded in the 
hard disc 22 and moves various data to the internal 
30 memory 24. Moreover, the MPU 1 2 performs an opera- 
tion for adjusting the processing units connected via the 
internal bus 26. 

[0065] The 1394 interface 14 can receive the image 
data transferred onto the 1 394 serial bus and also trans- 

35 mit the image data recorded in the hard disc 22 and the 
internal memory 24 to the 1 394 serial bus. Moreover, 
the 1394 interface 14 can transmit the command data 
for remotely operating the other nodes on the 1 394 se- 
rial bus. Furthermore, the 1394 interface 14 also has a 

40 function of transferring to the other nodes the signal 
transferred via the 1 394 serial bus. 
[0066] A user selects a desired soltware via the oper- 
ation unit 16, and causes the MPU 12 to operate the 
software recorded in the hard disc 22. Here, the infor- 

45 mation regarding the software is presented to the user 
by the display 20. The decoder 1 8 decodes the image 
data received on the 1 394 serial bus based on the soft- 
ware. The decoded image data is presented to the user 
by the display 20. 

so [0067] The function and operation of the processing 
units constituting the DVCR 28 will next be described. 
[0068] In the embodiment the DVCR 28 serves, for 
example, as an image transmission device (source 
node) for performing Asynchronous transfer of the im- 

55 age data based on the communication protocol of the 
embodiment. 

[0069] The image pickup unit 30 converts an optical 
image of the object into the electric signal constituted of 



5 



8/18/06, EAST 



Version: 2.0.3.0 



9 



EP 0 938 218 A2 



10 



a luminance signal Y and a color difference signal C, 
and supplies the electric signal to the A/D converter 32. 
The A/D converter 32 digitizes the electric signal. 
[0070] The video processing unit 34 applies a prede- 
termined image processing to the digitized luminance 
signal and color difference signal, and multiplexes the 
signals. The compression/expansion unit 36 compress- 
es the data amount of the digitized luminance signal and 
color difference signal. Here, the compression/expan- 
sion unit 36 uses an independent compression process- 
ing circuit to process the luminance signal and the color 
difference signal in parallel. Alternatively, the unit may 
use a common compression processing circuit to proc- 
ess the signals in time division. 
[0071] Moreover, in order to be resistant to errors in 
transmission paths, the compression/expansion unit 36 
applies a shuffling processing to the compressed image 
data. Thereby, a continuous code error (i.e., burst error) 
can be converted to a discrete error (i.e., random error) 
which can easily be repaired or interpolated. Here, when 
a deviation of information amount due to a coarse image 
in screen is uniformed, this process may preferably be 
performed prior to the compression process, which is 
convenient for the encoding with a variable run length 
or another length. 

[0072] In the compression/expansion unit 36, data 
identification information ID is added to the compressed 
image data in order to restore the shuffling. The com- 
pression/expansion unit 36 adds an error correction 
code ECC to the compressed image data in order to re- 
duce errors at the time of recording/reproducing. 
[0073] The image data compressed in the compres- 
sion/expansion unit 36 is supplied to the memory 38 and 
the recorder/reproducer 58. The recorder/reproducer 58 
records the compressed image data with ID and ECC 
added thereto to the magnetic tape or another storage 
medium. Here, the compressed image data is recorded 
into a recording area different from or independent of an 
area for the audio data. 

[0074] On the other hand, the image data supplied to 
the D/A converter 56 from the video processing unit 34 
is D/A converted. The E VF 54 indicates an analog image 
signal supplied from the D/A converter 56. Moreover, the 
image data processed in the video processing unit 34 is 
also supplied to the memory 40. Here, non-compressed 
image data is stored in the memory 40. 
[0075] The data selector 42 selects the memory 38 or 
40 based on user's instruction, and supplies the com- 
pressed image data or the non-compressed image data 
to the 1 394 interface 44. Moreover, the data selector 42 
supplies the image data supplied from the 1 394 inter- 
face 44 to the memory 38 or 40. 
[0076] The 1 394 interface 44 performs Asynchronous 
transfer of the compressed image data or the non-com- 
pressed image data based on the communication pro- 
tocol of the embodiment as described later. Moreover, 
the 1 394 interface 44 receives a control command for 
controlling the DVCR 28 via the 1394 serial bus. The 



received control command is supplied to the system 
controller 50 via the data selector 42. The 1 394 interface 
44 returns a response to the control command. 
[0077] The function and operation of each processing 

s unit constituting the printer 60 will now be described. 
[0078] In the embodiment the printer 60 serves, for 
example, as an image receiving device (destination 
node) for receiving and printing the image data asyn- 
chronously transferred based on the communication 

io protocol of the embodiment. 

[0079] The 1 394 interface 62 receives the image data 
or the control command asynchronously transferred via 
the 1394 serial bus. Moreover, the 1394 interface 62 
sends a response to the control command. 

is [0080] The received image data is supplied to the de- 
coder 70 via the data selector 64. The decoder 70 de- 
codes the image data, and transmits results to the image 
processing unit 74. The image processing unit 74 tem- 
porarily stores the decoded image data to the memory 

20 72. 

[0081] Moreover, the image processing unit 74 con- 
verts the image data temporarily stored in the memory 
72 to data to be printed, and supplies the data to the 
printer head 78. The printer head 78 performs printing 

25 under control of the printer controller 68. 

[0082] On the other hand, the received control com- 
mand is transmitted to the printer controller 68 via the 
data selector 64. The printer controller 68 performs var- 
ious controls regarding the printing based on the control 

so data. For example, the sheet feeding by the driver 76, 
the position of the printer head 78, and the like are con- 
trolled. 

[0083] A structure of the 1 394 interface 14, 44, 62 of 
the embodiment will next be described in detail with ref- 

35 erence to Fig. 8. 

[0084] The 1394 interface is functionally constituted 
of a plurality of layers. In Fig. 8, the 1394 interface is 
connected to the 1394 interface of another node via a 
communication cable 801 conforming to the IEEE 

w 1394-1995 standards. Moreover, the 1 394 interface has 
at least one communication port 802, and each commu- 
nication port 802 is connected to a physical layer 803 
included in hardware. 

[0085] In Fig. 8, the hardware is constituted of the 
4S physical layer 803 and a link layer 804. The physical lay- 
er 803 performs physical, electrical interface with the 
other nodes, detection of bus reset and processing, en- 
coding/decoding of input/output signals, reconciliation 
of bus using rights, and the like. Moreover, the link layer 
50 804 performs generation of communication packet, 
transmission/reception of various communication pack- 
ets, control of a cycle timer, and the like. Furthermore, 
the link layer 804 provides a function of generating and 
transmitting/receiving Asynchronous broadcast packet 
55 as described later. 

[0086] Moreover, in Fig. 8, firmware includes a trans- 
action layer 805 and a serial bus management 806. The 
transaction layer 805 controls Asynchronous transfer 
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system, and provides various transactions (read, write, 
lock). Furthermore, the transaction layer 805 provides 
a function of Asynchronous broadcast transaction as 
described later. The serial bus management 606 pro- 
vides functions for controlling self node, and for manag- 
ing connection state of the self node, ID information of 
the self node, and source of serial bus network on the 
basis of IEEE 1 21 2 CSR standard described later. 
[0087] The hardware and firmware shown in Fig. 8 
substantially constitute the 1394 interface, and basic 
structures are defined by the IEEE 1394-1995 stand- 
ards. 

[0088] Moreover, an application layer 807 included in 
software varies with application soft for use, and it is 
controlled how and what object data is transferred. 
[0089] The communication protocol of the embodi- 
ment described later expands the function of the hard- 
ware and firmware constituting the 1 394 interface, and 
provides the software with a new transfer procedure. 
[0090] A basic structure of the communication proto- 
col defined in the embodiment will next be described 
with reference to Fig. 3. 

[0091] Fig. 3 shows a controller 300, a source node 
302, n (n>l ) destination nodes 304, a subunit 306 of the 
source node, and an object 308 such as still image data, 
graphic data, text data, file data, program data, and the 
like. 

[0092] A first memory space 310 provided inside the 
destination node 304 is designated by a predetermined 
destination offset (destination_offset #0). A first connec- 
tion 312 indicates a logical connection relationship (that 
is, connection) between the source node 302 and the 
destination node 304. Here, the destination offset 
means an address for designating in common the mem- 
ory space of the n destination nodes 304. 
[0093] N-th memory space 314 provided inside the 
destination node 304, is designated by a predetermined 
destination offset (destination_offset fin). An n-th con- 
nection 316 indicates a logical connection relationship 
(that is, connection) between the source node 302 and 
the destination node 304. 

[0094] In the embodiment, each node controls the first 
memory space 31 0 to the n-th memory space 31 4 by an 
address space of 64 bits conforming to IEEE 1212 CSR 
(Control and Status Register Architecture) standards (or 
ISO/IEC 13213: 1 994 standards). The IEEE 1212 CSR 
standards define control for serial bus, management, or 
address allotment. 

[0095] Figs! 6A and 6B are explanatory views of the 
address space of each node. Fig. 6A shows a logical 
memory space represented by the address of 64 bits. 
Moreover, Fig. 6B shows a part of the address space 
shown in Fig. 6A, for example, an address space in 
which high-order 16 bits form FFFF 16 . As the first mem- 
ory space 310 to the n-th memory space 314 shown in 
Fig. 3, a part of the memory space shown in Fig. 6B is 
used. Each of the memory spaces 3 1 0 to 3 1 4 is defin ed 
by the destination offset indicating low-order 48 bits of 



the address. 

[0096] In Fig. 6B, for example, 000000000000 16 to 
0000000003FF 16 are reserved areas, and the areas 
where the object data 308 is actually written are areas 
s from FFFFF0000400 16 indicating low-order of the 48 
bits. 

[0097] In Fig. 3, the source node 302 has a function 
of transferring the object data 308 in accordance with 
the communication protocol described later, while the 

>o destination node 304 has a function of receiving the ob- 
ject data 308 transferred from the source node 302. 
Moreover, the controller 300 establishes the logical con- 
nection relationship (that is, connection) between the 
source node 302 and at least one destination node 304 

is in accordance with the communication protocol de- 
scribed later, and controls the connection. 
[0098] Here, the controller 300, the source node 302, 
and the destination node 304 may function in separate. 
Moreover, the controller 300 and the source node 302 

20 may function in the same node. Furthermore, the con- 
troller 300 and the destination node 304 may function in 
the same node. In this case, no transaction is necessary 
between the controller 300 and the source node 302 or 
the destination node 304, which simplifies the commu- 

25 nication procedure. 

[0099] In the embodiment, a case where the controller 
. 300, the source node 302, and the destination node 304 
separately function in independent nodes will be de- 
scribed. For example, the computer 10 provided with the 

30 1394 interface 14 serves as the controller 300. Moreo- 
ver, the DVCR 28 provided with the 1 394 interlace 44 
serves as the source node 302, while the printer 60 pro- 
vided with the 1394 interface 62 serves as the destina- 
tion node 304. 

35 [0100] In the embodiment, as shown in Fig. 3, at least 
one connection can be set between the source node 302 
and at least one destination node 304. When there is a 
request for transfer of certain object data, these connec- 
tions are set by at least one controller 300 based on the 

40 communication protocol described later. 

[0101] In the embodiment, one or more destination 
offset usable in one connection can be set. The value 
of the destination offset may be preset or set variably by 
the controller 300 or the source node 302. Additionally, 

45 a relationship of the connection and the destination off- 
set is set based on the communication protocol de- 
scribed later. 

[0102] When a plurality of destination offsets are set 
in one connection, a plurality of modes of data coramu- 

so nication can simultaneously be realized with one con- 
nection. For example, one to one, one to N, N to N data 
communication can simultaneously be realized with one 
connection by allocating different destination offsets to 
the modes of the data communication. 

ss [0103] Additionally, in the embodiment, the computer 
10 as the controller 300 may operate as the destination 
node 304. In this case, a connection is set between one 
source node 302 and two destination nodes 304, and 
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the object data 308 is transferred. 

[0104] Moreover, in the embodiment, the case where 

the computer 10 serves as the controller 300 has been 

described, but the computer 10 does not necessarily 

have to function as the controller 300. The DVCR 28 or 

the printer 60 may operate as the controller 300. First 

Embodiment 

[0105] A basic transfer procedure of the communica- 
tion protocol defined in the first embodiment will next be 
described. 

[010$] Figs. 4A, 4C are sequence charts showing a 
procedure performed until one object data is trans- 
ferred. Fig. 4B shows a sequence chart showing a trans- 
fer procedure if bus reset or transmission error occurs 
during the transfer of one object data. 
[0107] In the communication protocol of the embodi- 
ment, after the aforementioned connection is set by the 
controller 300, one object data is transferred at least one 
Asynchronous broadcast transaction. A detailed com- 
munication procedure of Asynchronous broadcast 
transaction will be described with reference to Fig. 4. 
Additionally, a packet for use in Asynchronous broad- 
cast transaction (hereinafter referred to as Asynchro- 
nous broadcast packet) will be described with reference 
to Fig. 5. 

[0108] Additionally, the Asynchronous broadcast 
transaction and Asynchronous broadcast packet are 
completely new communication procedure and packet 
format defined in the communication protocol of the em- 
bodiment. 

[0109] The basic transfer procedure based on the 
communication protocol of the embodiment will be de- 
scribed hereinafter with reference to Figs. 4A, C. Here, 
Fig. 4A is a sequence chart showing a case where data 
communication is performed with one destination node 
304 in one connection. Moreover, Fig. 4C is a sequence 
chart showing a case where data communication is per- 
formed with three destination nodes 304 in one connec- 
tion. 

[0110] The controller 300 sets connection I D for iden- 
tifying the logical connection relationship (connection) 
between the source node 302 and at least one destina- 
tion node 304. Subsequently, the controller 300 notifies 
each node of the connection ID, and sets one connec- 
tion (401, 402 of Fig. 4A, 4C). 
[0111] After the notification of the connection ID, the 
controller 300 commands the source node 302 to start 
the transfer of the object data 308 (403 of Fig. 4A, 4C) 
[0112] After receiving the transaction command, the 
source node 302 executes negotiation with at least one 
destination node 304 to perform initialization of Asyn- 
chronous broadcast transaction (404, 405 of Fig. 4A, 
4C). 

[0113] After the initialization setting is completed, the 
source node 302 performs Asynchronous broadcast 
transaction to successively broadcast the object data 
308 constituted of one or more segment data (406 to 
409 of Fig. 4A, 4C) 



[0114] Here, a transfer model of object data in the em- 
bodiment will be described with reference to Fig. 7. In 
Fig. 7, the object data is, for example, still image data 
with a data size of 128 Kbytes. 

s [0115] The source node 302 segments the object data 
308, for example, into 500 pieces of segment data (one 
piece of segment data corresponds to 256 bytes) in ac- 
cordance with reception ability of each destination node 
304 recognized in the initialization setting. Here, the size 

10 of one segment data is variously set by the source node 
302 in accordance with the size of an internal buffer of 
each destination node 304. Fig. 7 shows a case where 
the internal buffer with the same size as the size of the 
object data 308 is secured. 

'5 [0116] Moreover, the source node 302 transfers one 
or more segment data using at least one Asynchronous 
broadcast transaction. In Fig. 7, one segment data is 
transferred using one Asynchronous broadcast transac- 
tion. 

20 [0117] Alter the transfer of all the segment data, the 
source node 302 completes the data communication 
with at least one destination node 304 (410, 411 of Fig. 
4A, 4C). 

[0118] The operation of the controller 300 will next be 

25 described in detail with reference to Figs. 4A, 4C. 
[0119] The controller 300 conducts negotiations to set 
connection between the source node 302 and at least 
one destination node 304 selected by the user. Subse- 
quently, the controller 300 performs Asynchronous 

30 transfer of a packet for setting the connection between 
the nodes (hereinafter referred to as the connection set- 
ting packet) (401, 402 of Fig. 4A, 4C). 
[0120] In this case, each destination node 304 notifies 
the controller 300 of a self allowable interval time (data 

35 transfer delay shown in Fig. 9). The controller 300 dy- 
namically determines an optimum period of time (re- 
sponse period shown in Fig. 9) in which the source node 
302 is on standby in each Asynchronous broadcast 
transaction, based on the interval- time of each destina- 

fo tibn node 304. For example, the maximum value of the 
interval time of each destination node 304 is deter- 
mined. The period is notified to the source node 302 
along with the connection setting packet. 
[0121] Additionally, the period is set longer than the 

45 interval time. Moreover, the interval time dynamically 
changes with the reception ability and performance of 
the destination node 304. Therefore, the interval time is 
shortened when the reception ability and performance 
are high, while it is lengthened when they are low. 

so [0122] The connection ID indicating the connection 
between the source node 302 and the destination node 
304 is stored in a payload of the connection setting pack- 
et. Each node identifies its set connection by the con- 
nection ID. Additionally, the connection is set by the con- 

ss troller 300 based on the connection I D already set to the 
source node 302 and the connection ID already set to 
each destination node 304. 

[0123] Subsequently, the controller 300 performs 
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Asynchronous transfer of a transmission command 
packet (transaction command packet) to the source 
node 302 (403 of Fig. 4A, 4C). 
[0124] Upon receipt of the transmission command 
packet, the source node 302 performs the initialization 
setting by using the connection ID notified from the con- 
troller 300 to execute Asynchronous broadcast transac- 
tion (404 to 409 of Fig. 4A, 4C). Through the Asynchro- 
nous broadcast transaction, the source node 302 can 
successively transfer the object data 308 constituted of 
one or more segment data. 

[0125] Additionally, in the communication protocol of 
the embodiment, the controller 300 provides a function 
of controlling connection/disconnection. Therefore, af- 
ter the connection is set, the object data 308 is trans- 
ferred by the negotiation between the source node 302 
and the destination node 304. 
[0126] After a series of Asynchronous broadcast 
transactions are completed, the source node 302 broad- 
casts Asynchronous broadcast packet indicating a seg- 
ment end (hereinafter referred to as the segment end 
packet) (410 of Fig. 4A, 4C). 

[0127] After receiving the segment end packet from 
the source node 302, the connection is released to com- 
plete the data transfer (41 1 of Fig. 4A, 4C). 
[0128] Here, since the segment end packet is broad- 
cast, the content of the packet can be detected even in 
the destination node 304. Therefore, instead of the con- 
troller 300, the destination node 304 may release the 
connection from the source node 302. 
[0129] The operation of the source node 302 will next 
be described in detail with reference to Figs. 4A, 4C. 
[0130] The source node 302 having received the con- 
nection setting packet and the transaction command 
packet from the controller 300 transmits Asynchronous 
broadcast packet (hereinafter referred to as the send re- 
quest packet) to each destination node 304 requesting 
for data transfer (404 of Fig. 4A, 4C). 
[0131] Here, the send request packet means a re- 
quest packet for obtaining necessary initial information 
before executing Asynchronous broadcast transaction 
of the object data 308. The connection ID designated by 
the controller 300 is written in the packet. 
[0132] The destination node 304 broadcasts Asyn- 
chronous broadcast packet (hereinafter referred to as 
the ack response packet) indicative of a response cor- 
responding to the send request packet (405 of Fig. 4A, 
4C). Here, the same connection ID as that in the send 
request packet is stored in the ack response packet. 
Therefore, the source node 302 can identify via which 
connection the ack response packet is transferred, by 
confirming the connection ID of the received packet. 
[0133] Here, the size of the internal buffer in which 
each destination node 304 can be secured, and an off- 
set address for designating the predetermined memory 
space are stored in the ack request packet. After receiv- 
ing the ack request packet, the source node 302 sets 
the destination offset for designating a common memory 



space for the destination nodes 304, and starts Asyn- 
chronous broadcast transaction. Here, the destination 
offset is set by using the offset address included in the 
ack request packet of each destination node 304. 

s [0134] Additionally, in the embodiment, the destina- 
tion offset used in Asynchronous broadcast transaction 
is set using the offset address included in the ack re- 
quest packet, which is not limited. For example, the con- 
troller 300 may be provided with a function of controlling 

<o the destination offset used by each connection, so that 
the destination offset is set along with the connection 
ID. In this case, the destination offset corresponding to 
each connection is notified to the source node 302 from 
the controller 300. 

'5 [0135] Moreover, each destination node 304 may di- 
rectly notify the source node of the interval time using 
the ack request packet. In this case, instead of the con- 
troller 300, the source node 302 dynamically determines 
an optimum period of time in which the source node 302 

20 is on standby in each Asynchronous broadcast transac- 
tion. 

[01 36] Subsequently, the source node 302 writes the 
first Asynchronous broadcast packet in the memory 
space indicated by the destination offset (406 of Fig. 4A, _ 

25 4C). The connection ID and the sequence number of the 
segment data are stored in the packet. 
[0137] After transmitting the first Asynchronous 
broadcast packet, the source node 302 waits for a re- 
sponse packet from the destination node 304. The des- 

30 tination node 304 transmits the response packet in 
which the connection ID and the sequence number are 
stored, in the format of Asynchronous broadcast packet. 
After receiving the response packet, the source node 
302 increments the sequence number, and transfers 

as Asynchronous broadcast packet including the next seg- 
ment data (407 ol Fig. 4A, 4C). 
[01 38] The source node 302 repeals the procedure to 
successively perform Asynchronous broadcast transac- 
tion (408, 409 of Fig. 4A, 4C). The period of time in which 

40 the response from the destination node 304 is waited 
for is determined by the interval time. The period of time 
is referred to as the response period in the embodiment. 
[0139] For example, even after the response period 
elapses after Asynchronous broadcast transaction of 

45 the i-th segment data, the response packet cannot be 
received. In this case, the source node 302 resends the 
same Asynchronous broadcast packet as that of the i- 
th segment data. 

[0140] Moreover, when the response packet is trans- 
50 (erred from the destination node 304 requesting for re- 
send, the source node 302 can broadcast the data of 
the designated sequence number again. 
[0141] After Asynchronous broadcast packet transac- 
tion of all the object data 308 is performed, the source 
55 node 302 broadcasts the segment end packet, and com- 
pletes the data transfer (410, 411 of Fig. 4A, 4C). 
[0142] Here, as described above, the source node 
302 segments the object data 308 into one or more seg- 
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ment data as required. In Asynchronous broadcast 
transaction of each segment data, the aforementioned 
response packet is generated. One segment data is 
transferred by performing Asynchronous broadcast 
transaction once. The destination node 304 has the vol- 
ume of buffer, which is indicated by the buffer size. 
[0143] Additionally, in the embodiment, the response 
packet is necessarily sent out in Asynchronous broad- 
cast transaction of one segment data, which is not lim- 
ited. After the data buffer of the destination node 304 is 
filled with a plurality of continuous segment data, the 
destination node 304 may transmit the response packet. 
In the structure, since the frequency of the response op- 
eration performed by the destination node 304 can be 
reduced, the structure of the destination node 304 can 
be simplified, and the processing rate can be enhanced. 
[0144] The operation of the destination node 304 will 
next be described in detail with reference to Figs. 4A, 
4C. 

[0145] The destination node 304 having received the 
connection setting packet from the controller 300 waits 
for the send request packet from the source node 302 
(404 of Fig. 4A, 4C). 

[0146] The destination node 304 having received the 
send request packet confirms the connection ID written 
in the packet and the connection ID notified from the 
controller, and determines whether or not the packet is 
transferred from the source node 302. 
[0147] After receiving the send request packet from 
the source node 302, each destination node 304 broad- 
casts the connection ID, the size of the internal buffer 
which can be secured, and the ack response packet in 
which the offset address designating the predetermined 
memory space is written (405 of Fig. 4A, 4C). Addition- 
ally, each destination node 304 may directly notify the 
source node 302 of the interval time by using the send 
request packet. 

[0148] After the Asynchronous broadcast packet 
transferred from the source node 302 is written in the 
memory space, the destination node 304 confirms the 
connection ID of the packet. When the connection ID 
included in the packet coincides with the connection ID 
of the destination node 304 itself, the response packet 
in which the connection ID and the sequence number 
are stored is broadcast (406 to 409 of Fig. 4A, 4C). In 
this case, the segment data included in the received 
packet is stored in the internal buffer. Here, when the 
connection ID included in the received packet is different 
from its connection ID, the destination node 304 dis- 
cards the received packet. 

[0149] Moreover, when the destination node 304 de- 
tects mismatching of the sequence number of the re- 
ceived packet, the response packet may be sent out re- 
questing for resend. In this case, the destination node 
304 designates the sequence number for the resend re- 
quest, and notifies the source node 302 of the number. 
[0150] When all the Asynchronous broadcast trans- 
actions are completed, the segment end packet is 



broadcastf rom the source node 302. Upon receiving the 
packet, the destination node 304 completes the data 
transfer process (410 of Fig. 4A, 4C). 
[0151] After receiving the segment end packet, the 
s destination node 304 broadcasts the response packet 
indicating that the segment end packet is normally re- 
ceived (411 of Fig. 4A, 4C). 

[0152] As described above, the communication sys- 
tem of the embodiment can solve inconveniences of the 
10 conventional communication system. Moreover, even in 
the data transfer requiring no real-time properties, the 
data can easily be transferred at high speeds. 
[0153] Furthermore, in the embodiment, afterthe con- 
troller 300 sets the connection, the process of transfer- 
is ring the object data is performed between the source 
node 302 and each destination node 304 without being 
controlled by the controller 300. Therefore, there can be 
provided a simple communication protocol in which the 
load of the controller 300 is reduced and no complicated 
20 communication procedure is necessary. 

[0154] Additionally, in the embodiment, the destina- 
tion node 304 is sure to send a response to each Asyn- 
chronous broadcast transaction. Therefore, there can 
be provided a communication protocol in which the data 
25 requiring no real-time properties can securely be trans- 
ferred. 

[0155] In order to realize more secure data transfer, 
when the data transfer is interrupted by occurrence of 
the bus reset or any transmission error, the data transfer 
so needs to be instantly resumed without dropping any da- 
ta. A resuming procedure defined in the communication 
protocol of the embodiment will be described hereinafter 
with reference to Fig. 4B. 

[0156] For example, when the bus reset occurs after 

35 Asynchronous broadcast packet with a sequence 
number i is received, each node discontinues the trans- 
fer process, and executes bus initialization, recognition 
of connection structure, setting of node ID, and the like 
in accordance with the procedure defined in the' IEEE 

40 1 394-1995 standards (420, 421 of Fig. 4B). 

[0157] After bus reconstruction is completed, each 
destination node 304 broadcasts a resend request 
packet in which the connection ID and the sequence 
number i are stored (422 of Fig. 4B). 

4S [0158] When Asynchronous broadcast transaction 
can be resumed, the source node 302 confirms the con- 
nection ID of the received resend request packet to 
broadcast the ack response packet in which the connec- 
tion ID is stored (423 of Fig. 4B). 

so [0159] Subsequently, the source node 302 succes- 
sively broadcasts the segment data of and after the se- 
quence number requested by the received resend re- 
quest packet, i.e., the sequence data starting with se- 
quence number i+1 (424 of Fig. 4B). 

ss [0160] In the aforementioned procedure, even if the 
data transfer is interrupted, the controller 300, the 
source node 302, and the destination node 304 can eas- 
ily and securely resume the subsequent data transfer 
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without considering each node ID. 
[0161] Moreover, as described above, in the embod- 
iment, even when the data transfer is interrupted, the 
control procedure of the controller 300 can effectively 
be simplified. 

[0162] The structure of Asynchronous broadcast 
packet defined in the embodiment will next be described 
with reference to Fig. 5. Asynchronous broadcast pack- 
et is, for example, data packet having a unit of 1 Quadlet 
(4 bytes=32 bits). 

[0163] First, a structure of packet header 521 will be 
described. 

[0164] In Fig. 5, a field 501 (16 bits) indicates 
destinationJD, and a node ID of a destination (i.e., des- 
tination node 304). In the communication protocol of the 
embodiment, in order to realize Asynchronous broad- 
cast transaction of the object data 308, a value of the 
field is set as broadcasting ID (i.e., FFFF 16 ). 
[01 65] A field 502 (6 bits) indicates a transaction label 
(tl) field, or a tag peculiar to each transaction. 
[0166] A field 503 (2 bits) indicates a retry (rt) code, 
and designates whether or not the packet makes a retry. 
[01 67] A field 504 (4 bits) indicates a transaction code 
(tcode), which designates a packet format or a transac- 
tion type to be executed. In the embodiment, a value of 
the field is set, for example, to 000 1 2 to request for a 
process of writing a data block 522 of the packet into the 
memory space indicated by a destination_offset field 
507 (i.e., write transaction). 

[01 68] A field 505 (4 bits) indicates a priority (pri), and 
designates the order of priority. In the embodiment, a 
value of the field is set to 0000 2 . 
[0169] Afield 506 (16 bits) indicates sourceJD, orthe 
node ID of the transmission side (i.e., source node 302). 
[0170] The field 507 (48 bits) indicates 
destination_offset, and designates low-order 48 bits of 
the address space of each destination node 304 in com- 
mon. Here, for destination_offset, the same value may 
be set in all the connections, or different values may be 
set in the connections. However, when the different val- 
ues are set, Asynchronous broadcast packets from a 
plurality of connections can efficiently be processed in 
parallel. 

[0171] Afield 508 (16 bits) indicates datajength, and 
indicates a length of data field described later in units of 
bytes. 

[0172] A field 509 (16 bits) indicates extendedjcode. 
In the embodiment, a value of the field is set to 0000 16 . 
[0173] A field 510 (32 bits) indicates header_CRC, in 
which error detecting codes for the fields 501 to 509 are 
stored. 

[0174] A structure of the data block 522 will next be 
described. In the embodiment, the data block 522 is con- 
stituted of a header information 523 and a data field 524. 
[0175] A connection ID for identifying a logical con- 
nection relationship between the nodes, and the like are 
stored in the header information 523. 
[0176] Moreover, the data field 524 has a variable 



length, in which the segment data is stored. Here, when 
the segment data stored in the data field 524 is not a 
multiple of Quadlet, a portion not satisfying Quadlet is 
filled with zero. 

s [0177] A field 511 (16 bits) indicates connectionJD, 
and stores the connection ID of the embodiment. The 
1 394 interlace of the embodiment identifies the connec- 
tion set between the source node 302 and at least one 
destination node 304 based on the connection I D stored 

io h the field. In the embodiment, connections of 2 16 xthe 
number ol nodes can be established. Therefore, a plu- 
rality of connections can be set until the total amount of 
communication band used by each connection reaches 
the volume of the transmission path. 

is [01 78] A field 51 2 (8 bits) indicates protocoljype, and 
communication procedure based on the header infor- 
mation 523 (i.e., communication protocol type) is indi- 
cated. When the communication protocol of the embod- 
iment is indicated, a value of the field is, for example, 

20 01 16 . 

[0179] A field 51 3 (8 bits) indicates controljlags, and 
predetermined control data for controlling communica- 
tion procedure and the like of the communication proto- 
col of the embodiment are set. In the embodiment, a 

2S most significant bit of the field is set, for example, as a 
resend_request flag. Therefore, when the most signifi- 
cant bit of the field has a value of 1 , it is indicated that 
the resend request based on the communication proto- 
col of the embodiment is generated. 

so [0180] A field 514 (16 bits) indicates 
sequence_number, and a continuous value (i.e., se- 
quence number) is set to a packet transferred based on 
a specified connection ID (connection ID designated by 
the field 511). The destination node 304 can monitor 

35 continuity of segment data successively subjected to 
Asynchronous broadcast transaction by the sequence 
number. When an inequality occurs, the destination 
node 304 can request for resend based on the sequence 
number. 

*o [0181] A field 515 (16 bits) indicates 
reconf irmation_number. In the embodiment the field has 
a meaning only when the resend request flag has a val- 
ue of 1 . For example, when the value of the resend re- 
quest flag is 1, the sequence number of the packet re- 

45 questing for resend is set in the field. 

[0182] A field 516 (16 bits) indicates buffer_size. The 
buffer size of the destination node 304 is set in the field. 
[0183] A field 517 (48 bits) indicates offset_address. 
Low-order 48 bits of the address space of the destina- 

50 tion node 304 are stored in the field. Therefore, any one 
of first memory space 310 to n-th memory space 314 
shown in Fig. 3 is designated. 
[0184] A field 518 (32 bits) indicates 
destination_interval. The interval time is stored in the 

55 field. Each destination node 304 notifies the source 
node 302 and the controller 300 of the interval time by 
the field. 

[0185] A field 51 9 (32 bits) indicates data_CRC, and 
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error detecting codes for the fields 5 1 1 to 51 8 (including 
the header inlormation 523 and the data field 524) are 
stored in the same manner as the header_CRC. 
[0186] The communication protocol of the first em- 
bodiment will nexl be described in detail with reference 
to Fig. 9. 

[0187] In Fig. 9, particularly a time interval between a 
time when the i-th (i being an optional integer) Asynchro- 
nous broadcast transaction is executed and a time when 
the (i+1 )-th Asynchronous broadcast transaction is ex- 
ecuted will be described in detail. Additionally, in Fig. 9, 
to simplify the description, transfer between one source 
node 302 and one destination node 304 is shown, but 
the same processing can be performed even when more 
than one destination node 304 are provided. 
[0188] Fig. 9 shows an internal buffer 252 of the des- 
tination node 304; a next-stage circuit 254 for process- 
ing data of the internal buffer 252; an i-th Asynchronous 
broadcast packet 256; a response packet 258 corre- 
sponding to the i-th Asynchronous broadcast packet; an 
(i+1)-th Asynchronous broadcast packet 260; a re- 
sponse packet 262 corresponding to the (i+1)-th Asyn- 
chronous broadcast packet; a response period 267: da- 
ta movement 266 inside the destination node 304 (from 
internal buffer 252 to next-stage circuit 254); and a delay 
time 268 in the data movement inside the destination 
node 304. 

[0189] When the i-th Asynchronous broadcast trans- 
action is started, the i-th Asynchronous broadcast pack- 
et 256 is transferred from the source node 302. The des- 
tination node 304 temporarily stores the segment data 
included in the packet into the internal buffer 252 via the 
predetermined memory space, and then the segment 
data moves to the next-stage circuit 254. 
[0190] When the movement of the segment data is 
completed, the destination node 304 prepares the re- 
sponse packet 258 indicative of the completion, and 
transfers the packet to the source node 302. In this case, 
the delay time 268 dependent on the performance of the 
destination node 304 is generated in the transfer of the 
response packet 258 along with data movement 266 in- 
side the destination node 304. 
[0191] Expected delay time 268 of the destination 
node 304 is notified as the interval time to the source 
node 302 from the controller 300 beforehand. The 
source node 302 determines the response period 264 
based on the interval time. During this time, the source 
node 302 waits for the response packet from the desti- 
nation node 304, and executes no next Asynchronous 
broadcast transaction. Here, the response period 264 is 
usually set longer than the interval time. 
[0192] For the (i+1)-th Asynchronous broadcast 
transaction, processing is performed in the same pro- 
cedure as in the i-th Asynchronous broadcast transac- 
tion. Subsequently, since each Asynchronous broad- 
cast transaction is processed in the same manner, all 
the Asynchronous broadcast packets are securely 
transferred without being resent. 



[0193] In the aforementioned structure, at the time of 
setting the connection the controller 300 (or the source 
node 302) of the first embodiment can dynamically set 
the optimum response period in accordance with the re- 
5 ception ability and performance of each destination 
node 304. For example, the period is set short when the 
reception ability and performance of the destination 
node 304 are high, while the period is set long when 
they are low. 

w [0194] Therefore, even when the performance of 
each destination node 304 is not very high, the source 
node 302 can securely execute each Asynchronous 
broadcast transaction without frequently generating the 
resending process. Moreover, the transfer efficiency in 

is the network is prevented from being lowered. Addition- 
ally, since the destination node 304 does not require 
high-speed, high-function reception ability, costs neces- 
sary for realizing the function of the destination node 304 
can be reduced. 

20 

Second Embodiment 

[0195] A communication protocol of a second embod- 
iment will be described hereinafter with reference to Fig. 

2S 10 to 16. In the second embodiment, particularly a pro- 
cedure for preventing a retry from being unnecessarily 
generated will be described in detail. The retry is inhib- 
ited only for a predetermined time when an i-th data is 
not normally received. 

ao [0196] Fig. 10 is a state transition view showing a retry 
procedure of the source node 302 provided with a single 
phase retry function defined in the embodiment. 
[0197] The source node 302 transfers 1o OSR0 state 
from another state in response to a transaction control 

3S request to Initialize of Reset from its node controller 
(1001 of Fig. 10). In this state, the source node 302 is 
prepared for transmitting a predetermined packet to 
each destination node 304. Therefore, in the state, when 
a response packet indicating an acknowledge code oth- 

40 er than ack_busy_A, ack_busy_X is received from the 
destination node 304, the source node 302 can transfer 
the next packet, and does not need to perform retrying 
(1006 of Fig. 10). 

[0198] In the OSR0 state, when the source node 302 
45 receives a response packet indicative of ack_busy_A, 
ack_busy_B or ack_busy_X, the source node 302 rec- 
ognizes that the destination node 304 is busy. In this 
case, the source node 302 changes the state from 
OSR0 to OSR1, and executes retrying (1002 of Fig. 10). 
so [0199] In the OSR1 state, when there is a pending re- 
try to be processed, the source node 302 processes the 
retry before transferring another optional packet. In this 
case, the source node 302 designates the retry code to 
retry_X to perform retrying. 
ss [0200] In the OSR1 state, when the source node 302 
does not exceed a retry limit, and the pending retry pack- 
et is not placed in a retry queue, the source node 302 
again repeats retrying (1007 of Fig. 10). Here, the retry 
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queue means a queue of retry packets. 
[0201] Moreover, in the OSR1 state, a minimum retry 
period is set in the source node 302. The source node 
302 stays in the OSR1 state without performing retrying 
until the minimum retry period elapses (1008 of Fig. 10). 
[0202] In the OSR1 state, when the retry limit is not 
exceeded, and the retry packet is placed in the retry 
queue, the source node 302 transfers to the OSR0 state 
from the OSR1 state (1005 of Fig. 10). 
[0203] Moreover, in the OSR1 state, when the re- 
sponse packet indicative of the acknowledge code other 
than ack_busy_A, ack_busy_B and ack_busy_X, it is 
judged that the retry has been processed, and the 
source node 302 changes to the OSR0 state from the 
OSR1 state (1003 of Fig. 10). 
[0204] Furthermore, in the OSR1 state, when the 
source node 302 performs the retry of a certain packet 
until the retry limit is exceeded, it is judged that the retry 
has failed, and the source node 302 changes to the 
OSR0 state from the OSR1 state (1004 of Fig. 10). 
[0205] Fig. 1 1 is a state transition view showing a retry 
procedure of the source node 302 provided with a dual 
phase retry function defined in the embodiment. Addi- 
tionally, the source node 302 supporting the dual phase 
retry function also supports the single phase retry func- 
tion. 

[0206] The source node 302 changes to an ODR0 
state from another state in response to a transaction 
control request to Initialize or Reset from its node con- 
troller (1101 of Fig. 11). In this state, the source node 
302 is prepared for transmitting a predetermined packet 
to each destination node 304. The source node 302 sets 
the retry code to retry_1 , and is on standby. 
[0207] In the ODR0 state, when the response packet 
other than ack_busy_A, ack_busy_B and ack_busy_X 
is received from each destination node 304, the source 
node 302 can transfer the next packet, and does not 
need to perform retrying (1107 of Fig. 11). 
[0208] In the ODR0 state, when the response packet 
of ack_busy_A or ack_busy_B is received from a certain 
destination node 304, the source node 302 judges that 
the destination node 304 is a node supporting the dual 
phase retry function and is busy. In this case, the source 
node 302 performs retrying in accordance with the dual 
phase retry function. 

[0209] When the response packet indicative of 
ack_busy_A is received, the source node 302 executes 
a retry phase A, and changes to an ODR1 state from 
the ODR0 state (1102 of Fig. 11). Moreover, when the 
response packet indicative of ack_busy_B is received, 
the source node 302 executes a retry phase B, and 
changes to an ODR2 state from the ODR0 state (1108 
of Fig. 11). 

[0210] Moreover, in the ODR0 state, when the re- 
sponse packet of ack_busy_X is received from a certain 
destination node 304, the source node 302 judges that 
the destination node 304 is a node supporting the single 
phase retry function and is busy. In this case, the source 



node 302 performs retrying in accordance with the sin- 
gle phase retry function. When the response packet in- 
dicative of ack_busy_X is received, the source node 302 
changes to an ODR3 state from the ODR0 state (1113 

s of Fig. 11). 

[0211] In the ODR1 state, the source node 302 is ex- 
ecuting the retry phase A, and has a pending retry to be 
solved. In this state, the minimum retry period is set in 
the source node 302. The source node 302 stays in the 

io ODR1 state without performing retrying until the mini- 
mum retry period elapses (1106 of Fig. 11). 
[0212] In the ODR1 state, the source node 302 sets 
the retry code to retry _A, and performs retrying. In this 
case, when the response packet from the destination 

15 node 304 indicates ack_busy_A, andfourfairness inter- 
val timeout periods do not elapse, the source node 302 
again repeats retrying (1105 of Fig. 11). Here, the fair- 
ness interval timeout period means a period set in a pe- 
riod during which Asynchronous transfer is possible, 

20 which gives a fair access right to the node which is to 
use the network. 

[0213] Moreover, in the ODR1 state, when the re- 
sponse retry code including the acknowledge code oth- 
er than ack_busy_A and ack_busy_B is received, it is 

2S judged that the retry has been processed, and the 
source node 302 changes to the ODR0 state from the 
ODR1 state (1103 of Fig. 11). 
[021 4] Furthermore, in the ODR1 state, when the four 
fairness interval timeout periods elapse, il is judged that 

30 the retry has failed, and the source node 302 changes 
to the ODR0 state from the ODR1 stale (11 04 of Fig. 11). 
[0215] In the ODR2 state, the source node 302 is ex- 
ecuting the retry phase B, and has a pending retry to be 
solved. In this state, the minimum retry period is set in 

3S the source node 302. The source node 302 stays in the 
ODR2 state without performing retrying until the mini- 
mum retry period elapses (1112 of Fig. 11). 
[0216] In Vie ODR2 state, the source node 302 sets 
the retry code to retry_B, and performs retrying. In this 

40 case, when the response packet from the destination 
node 304 indicates ack_busy_B, and four fairness inter- 
val timeout periods do not elapse, the source node 302 
again repeats retrying (1111 of Fig. 11). 
[0217] Moreover, in the ODR2 state, when the re- 

45 sponse retry code including the acknowledge code oth- 
er than ack_busy_A and ack_busy_B is received, it is 
judged that the retry has been processed, and the 
source node 302 changes to the ODR0 state from the 
ODR2 state (1109 of Fig. 11). 

so [0218] Furthermore, in the ODR2 state, when the four 
fairness interval timeout periods elapse, it is judged that 
the retry has failed, and the source node 302 changes 
to the ODR0 state from the ODR2 state ( 1 1 1 0 of Fig. 1 1 ). 
[021 9] In the ODR3 state, the source node 302 is ex- 

ss ecuting the single phase retry, and has a pending retry 
to be solved. In this state, the minimum retry period is 
set in the source node 302. The source node 302 stays 
in the ODR3 state without performing retrying until the 
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minimum retry period elapses (1 1 1 7 of Fig. 1 1 ). 
[0220] In the ODR3 state, the source node 302 sets 
the retry code to retry _X, and performs retrying. In this 
case, when the response packet from the destination 
node 304 indicates ack_busy_X, and the retry limit is 
not exceeded, the source node 302 again repeals retry- 
ing (1116 of Fig. 11). 

[0221] Moreover, in the ODR3 state, when the re- 
sponse retry code including the acknowledge code oth- 
er than ack_busy_X is received, it is judged that the retry 
has been processed, and the source node 302 changes 
to the ODR0 state from the ODR3 state (1 1 1 4 of Fig. 1 1 ). 
[0222] Furthermore, in the ODR3 state, when the retry 
count is exceeded, it is judged that the retry has failed, 
and the source node 302 changes to the ODR0 state 
from the ODR3 state (1 1 1 5 of Fig. 11). 
[0223] As described above, since the structure has 
the predetermined retry period, the source node 302 of 
the embodiment can assure more secure communica- 
tion. Moreover, even if the bus is congested, the busy 
state of the destination node 304 is prevented from oc- 
curring frequently, and deadlock can be prevented. 
[0224] A transfer procedure based on the communi- 
cation protocol of the second embodiment will next be 
described with reference to Fig. 12. Additionally, the 
communication protocol of the second embodiment is 
basically processed in the same manner as the commu- 
nication protocol of the first embodiment. Therefore, the 
procedure for performing the same processing as in Fig. 
4 is denoted with the same code, and detailed descrip- 
tion thereof is omitted. Additionally, in Fig. 12, to simplify 
the description, transfer between one source node 302 
and one destination node 304 is shown, but the same 
processing can be performed even when more than one 
destination node 304 are provided. 
[0225] The controller 300 sets the connection ID for 
identifying a logical connection relationship between the 
source node 302 and at least one destination node 304. 
Subsequently, the controller 300 notifies each node of 
the connection ID, and sets one connection (401, 402 
of Fig. 12). 

[0226] After notifying the connection ID, the controller 
300 commands the source node 302 to start transferring 
the object data 308 (403 of Fig. 12). 
[0227] After receiving a transaction command, the 
source node 302 conducts negotiations with at least one 
destination node 304 to set initial Asynchronous broad- 
cast transaction (404, 405 of Fig. 12). 
[0228] After completing initialization, the source node 
302 executes Asynchronous broadcast transaction to 
successively broadcast the object data 308 constituted 
of one or more segment data (406 to 409 of Fig. 12). 
[0229] Here, the source node 302 transfers one or 
more segment data by performing Asynchronous broad- 
cast transaction at least once in the same manner as in 
the first embodiment. The object data 30S is segmented, 
for example, in a plurality of segments as shown in Fig. 
7, and one segment data is transferred by using Asyn- 



chronous broadcast transaction once. 
[0230] After all the segment data are transferred, the 
source node 302 completes the data communication 
with one or more destination nodes 304 (41 0, 411 of Fig. 
5 12). 

[0231] The operation of the controller 300 will next be 
described in detail with reference to Fig. 1 2. 
[0232] The controller 300 conducts negotiations to set 
a connection between the source node 302 selected by 
'0 the user and at least one destination node 304. Subse- 
quently, the controller 300 performs Asynchronous 
transfer of a packet for setting the connection between 
the nodes (hereinafter relerred to as the connection set- 
ting packet) (401, 402 of Fig. 12). 
is [0233] Here, the controller 300 has a function of con- 
trolling a destination offset used by each connection. 
The controller 300 uses an offset address notified from 
each destination node 304 to set a destination offset for 
designating in common a memory space of each desti- 
ne nation node 304. Alternatively, a destination offset cor- 
responding to a certain connection is set in a predeter- 
mined procedure. After the setting, the destination offset 
is notified to the source node 302 from the controller 
300. 

25 [0234] The connection ID indicating the connection 
between the source node 302 and the destination node 
304 is stored in a payload of the connection setting pack- 
et. Each node identifies a connection set to itself by the 
connection ID. Additionally, the connection ID is set by 
30 the controller 300 based on the connection ID already 
set to Ihe source node 302 and Ihe connection ID al- 
ready set to each destination node 304. 
[0235] Subsequently, the controller 300 performs 
Asynchronous transfer of a transaction command pack- 
as et to the source node 302 (403 of Fig. 1 2). 

[0236] Upon receipt of the transaction command 
packet, the source node 302 performs the initialization 
using the connection ID notified from the controller 300 
to execute Asynchronous broadcast transaction (404 to 
40 409 of Fig. 1 2). Through the Asynchronous broadcast 
transaction, the source node 302 can successively 
transfer the object data 308 constituted of one or more 
segment data. 

[0237] Additionally, in the communication protocol of 
45 the embodiment, the controller 300 provides a function 
of controlling connection/disconnection. Therefore, af- 
ter the connection is set, the object data 308 is trans- 
ferred by the negotiation between the source node 302 
and the destination node 304. 
so [0238] After a series of Asynchronous broadcast 
transactions are completed, the source node 302 broad- 
casts Asynchronous broadcast packet indicating a seg- 
ment end (hereinafter referred to as the segment end 
packet) (410 of Fig. 12). 
ss [0239] After receiving the segment end packet from 
the source node 302, the controller 300 releases the 
connection to complete the data transfer (411 of Fig. 12). 
[0240] Here, since the segment end packet is broad- 
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cast, the content of the packet can be detected even in 
the destination node 304. Therefore, instead of the con- 
troller 300, the destination node 304 itself may release 
the connection from the source node 302. 
[0241] The operation of the source node 302 will next 
be described in detail with reference to Fig. 12. 
[0242] The source node 302 having received the con- 
nection setting packet and the transaction command 
packet from the controller 300 transmits Asynchronous 
broadcast packet (hereinafter referred to as the send re- 
quest packet) to each destination node 304 requesting 
for data transfer (404 of Fig. 1 2). 
[0243] Here, the send request packet means a re- 
quest packet for obtaining necessary initial information 
before executing Asynchronous broadcast transaction 
of the object data 308. The connection ID designated by 
the controller 300 is written in the packet. 
[0244] The destination node 304 broadcasts Asyn- 
chronous broadcast packet (hereinafter referred to as 
the accepted response packet) indicative of a response 
corresponding to the send request packet (405 of Fig. 
12). Here, the same connection ID as that in the send 
request packet is stored in the accepted response pack- 
et. Therefore, the source node 302 can identify via which 
connection the accepted response packet is trans- 
ferred, by confirming the connection ID of the received 
packet. 

[0245] Here, the size of the internal buffer in which 
each destination node 304 can be secured is stored in 
the accepted response packet. After receiving the ac- 
cepted response packet, the source node 302 sets the 
destination offset for designating a common memory 
space for the destination nodes 304, and starts Asyn- 
chronous broadcast transaction. Here, the destination 
offset is notified by the controller 300. 
[0246] Subsequently, the source node 302 writes the 
first Asynchronous broadcast packet in the memory 
space indicated by .the destination offset (406 of Fig. 1 2). 
The connection I D and the sequence number of the seg- 
ment data are stored in the packet. 
[0247] After transmitting the first Asynchronous 
broadcast packet, the source node 302 waits for an ac- 
knowledge packet from each destination node 304 
(1201 of Fig. 12). The acknowledge packet transferred 
from each destination node 304 is constituted as shown 
in Fig. 1 3. Here, when the destination node 304 is busy, 
the source node 302 performs the two types of retry, so 
that more secure data transfer can be assured, while 
the deadlock can be prevented. 
[0248] After receiving the acknowledge packet, the 
source node 302 increments the sequence number, and 
transfers Asynchronous broadcast packet including the 
next segment data (407 of Fig. 1 2). 
[0249] The source node 302 repeats the procedure to 
successively perform Asynchronous broadcast transac- 
tion (408, 409 of Fig. 12). A maximum period of time 
during which the acknowledge packet from the destina- 
tion node 304 is waited for is determined beforehand. 



The period of time is referred to as the response period. 
The response period is set in the same manner as in the 
first embodiment. Even after the response period elaps- 
es after Asynchronous broadcast transaction of the i-th 
s segment data, the acknowledge packet is not returned. 
In this case, the source node 302 resends the same data 
as the segment data. 

[0250] Moreover, when the response packet is trans- 
ferred from the destination node 304 requesting for re- 
io send, the source node 302 can broadcast the data of 
the designated sequence number again. 
[0251] After Asynchronous broadcast packet transac- 
tion of all the object data 308 is performed, the source 
node 302 broadcasts the segment end packet, and corn- 
's pletes the data transfer (410, 411 of Fig. 12). 

[0252] Here, as described above, the source node 
302 segments the object data 308 into one or more seg- 
ment data as required. In Asynchronous broadcast 
transaction of each segment data, the aforementioned 
20 response packet is generated. One segment data is 
transferred by performing Asynchronous broadcast 
transaction once. The destination node 304 has the vol- 
ume of buffer which is indicated by the buffer size. 
[0253] Additionally, in the embodiment, the acknowl- 
25 edge packet is necessarily sent out in Asynchronous 
broadcast transaction of one segment data, which is not 
limited. After the internal buffer of the destination node 
304 is filled with a plurality of continuous segment data, 
the destination node 304 may transmit the acknowledge 
so packet. In the structure, since the frequency of the re- 
sponse operation performed by the destination node 
304 can be reduced, the structure of the destination 
node 304 can be simplified, and the processing rate can 
be enhanced. 

35 [0254] The operation of the destination node 304 will 
next be described in detail with reference to Fig. 12. 
[0255] The destination node 304 having received the 
connection setting packet from the controller 300 waits 
for the send request packet from the source node 302 

40 (404 of Fig. 12). 

[0256] The destination node 304 having received the 
send requesl.packet confirms the connection ID written 
in the packet and the connection ID notified from the 
controller, and determines whether or not the packet is 

45 transferred from the source node 302. 

[0257] After receiving the send request packet from 
the source node 302, each destination node 304 broad- 
casts the connection ID, and the accepted response 
packet in which the secured size of the internal buffer is 

so written (405 of Fig. 12). 

[0258] After the Asynchronous broadcast packet 
transferred from the source node 302 is written in the 
memory space, the destination node 304 confirms the 
connection ID of the packet. When the connection ID 

ss included in the packet coincides with the connection ID 
of the destination node 304 itself, the acknowledge 
packet is broadcast (406 to 409 of Fig. 1 2). In this case, 
the segment data included in the received packet is 
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stored in the internal buffer. Here, when the connection 
ID included in the received packet is different from its 
connection I D, the destination node 304 discards the re- 
ceived packet. 

[0259] Moreover, when the destination node 304 de- 
tects mismatching of the sequence number of the re- 
ceived packet, the packet may be sent out requesting 
for resend. In this case, the destination node 304 des- 
ignates the sequence number for the resend request, 
and notifies the source node 302 of the number. 
[0260] When all the Asynchronous broadcast trans- 
actions are completed, the segment end packet is 
broadcast from the source node 302. Upon receiving the 
packet, the destination node 304 completes the data 
transfer process (410 of Fig. 12). 
[0261] After receiving the segment end packet, the 
destination node 304 broadcasts the packet indicating 
that the segment end packet is normally received (411 
of Fig. 12). 

[0262] As described above, the communication sys- 
tem of the embodiment can solve inconveniences of the 
conventional communication system. Moreover, even in 
the data transfer requiring no real-time properties, the 
data can easily be transferred at high speeds. 
[0263] Furthermore, in the embodiment, alterthe con- 
troller 300 sets the connection, the process of transfer- 
ring the object data is performed between the source 
node 302 and each destination node 304 without being 
controlled by the controller 300. Therefore, there can be 
provided a simple communication protocol in which the 
load of the controller 300 is reduced and no complicated 
communication procedure is necessary. 
[0264] Additionally, in the embodiment, the destina- 
tion node 304 is sure to send a response to each Asyn- 
chronous broadcast transaction. Therefore, there can 
be provided a communication protocol in which the data 
requiring no real-time properties can securely be trans- 
ferred. 

[0265] In order to realize more secure data transfer, 
when the data transfer is interrupted by occurrence of 
the bus reset or any transmission error, the data transfer 
needs to be instantly resumed without dropping any da- 
ta. A resuming procedure defined in the communication 
protocol of the embodiment will be described hereinafter 
with reference to Fig. 4B. 

[0266] For example, when the bus reset occurs after 
Asynchronous broadcast packet with a sequence 
number i is received, each node discontinues the trans- 
fer process, and executes bus initialization, recognition 
of connection structure, setting of node ID, and the like 
in accordance with the procedure defined in the IEEE 
1394-1995 standards (420, 421 of Fig. 48). 
[0267] After bus reconstruction is completed, each 
destination node 304 broadcasts a resend request 
packet in which the connection ID and the sequence 
number i are stored (422 of Fig. 48). 
[0268] When Asynchronous broadcast transaction 
can be resumed, the source node 302 confirms the con- 



nection ID of the received resend request packet to 
broadcast the ack response packet in which the connec- 
tion ID is stored (423 of Fig. 4B). 
[0269] Subsequently, the source node 302 succes- 

6 sively broadcasts the segment data of and after the se- 
quence number requested by the received resend re- 
quest packet, i.e., the sequence data starting with se- 
quence number i+1 (424 of Fig. 4B). 
[0270] In the aforementioned procedure, even if the 

10 data transfer is interrupted, the controller 300, the 
source node 302, and the destination node 304 can eas- 
ily and securely resume the subsequent data transfer 
without considering each node ID. 
[0271] Moreover, as described above, in the embod- 

is iment, even when the data transfer is interrupted, the 
control procedure of the controller 300 can effectively 
be simplified. 

[0272] The structure of Asynchronous broadcast 
packet defined in the second embodiment will next be 

20 described with reference to Fig. 1 3. Additionally, in Fig. 
13, the field having the same function as that of Asyn- 
chronous broadcast packet of the first embodiment is 
denoted with the same code as in Fig. 5. 
[0273] First, a structure of packet header 521 will be 

25 described. 

[0274] In Fig. 13, a field 501 (16 bits) indicates 
destinationJD, and a node ID of a destination (i.e., des- 
tination node 304) is indicated. In the communication 
protocol of the embodiment, in order to realize Asyn- 

30 chronous broadcast transaction of the object data 308, 
a value of the field is set as broadcasting ID (i.e., 
FFFF 16 ). 

[0275] A field 502 (6 bits) indicates a transaction label 
(tl) field, or a tag peculiar to each transaction. 

35 [0276] A field 503 (2 bits) indicates a retry (rt) code, 
and designates whether or not the packet makes a retry. 
[0277] A field 504 (4 bits) indicates a transaction code 
(tcode), which designates a packet format or a transac- 
tion type to be executed. In the embodiment, a value of 

40 the field is set, for example, to 0001 2 to request lor a 
process of writing a data block 522 of the packet into the 
memory space indicated by a destination_offset field 
507 (i.e., write transaction). 

[0278] A field 505 (4 bits) indicates a priority (pri), and 
45 designates the order of priority. In the embodiment, a 
value of the field is set to 0000 2 . 
[0279] Afield 506 (16 bits) indicates sourceJD, or the 
node ID of the transmission side (i.e., source node 302). 
[0280] The field 507 (48 bits) indicates 
so destination_offset, and designates low-order 48 bits of 
the address space of each destination node 304 in com- 
mon. Here, for destination_offset, the same value may 
be set in all the connections, or different values may be 
set in the connections. However, when the different val- 
55 ues are set, Asynchronous broadcast packets from a 
plurality of connections can efficiently be processed in 
parallel. 

[0281] A field 508 ( 1 6 bits) indicates datajength, and 
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a length of data field described later is indicated in units 
of bytes. 

[0282] A field 509 (1 6 bits) indicates extendedjcode. 
In the embodiment, a value of the field is set to 0000, 6 . 
[0283] A field 51 0 (32 bits) indicates header_CRC, in 
which error detecting codes for the fields 501 to 509 are 
stored. 

[0284] A structure of the data block 522 will next be 
described. In the embodiment, the data block 522 is con- 
stituted of a header information 1 301 and a data field 
524. 

[0285] A connection ID for identifying a logical con- 
nection relationship between the nodes, and the like are 
stored in the header information 1 301 . 
[0286] Moreover, the data field 524 has a variable 
length, in which the segment data is stored. Here, when 
the segment data stored in the data field 524 is not a 
multiple of Quadlet, a portion not satisfying Quadlet is 
filled with zero. 

[0287] A field 511(16 bits) indicates connectionJD, 
and stores the connection ID of the embodiment. The 
1 394 interface of the embodiment identifies the connec- 
tion set between the source node 302 and at least one 
destination node 304 based on the connection ID stored 
in the field. In the embodiment, connections of 2 16 xthe 
number of nodes can be established. Therefore, a plu- 
rality of connections can be set until the total amount of 
communication band used by each connection reaches 
the volume of the transmission path. 
[0288] A field 51 2 (8 bits) indicates protocoljype, and 
communication procedure based on the header infor- 
mation 1301 (i.e., communication protocol type) is indi- 
cated. When the communication protocol of the embod- 
iment is indicated, a value of the field is, for example, 

01 16- 

[0289] A field 51 3 (8 bits) indicates controljlags, and 
predetermined control data for controlling communica- 
tion procedure and the like of the communication proto- 
col of the embodiment are set. In the embodiment, a 
most significant bit of the field is set, for example, as a 
resend_request flag. Therefore, when the most signifi- 
cant bit of the field has a value of 1 , it is indicated that 
the resend request based on the communication proto- 
col of the embodiment is generated. 
[0290] A field 514 (16 bits) indicates 
sequence_number, and a continuous value (i.e., se- 
quence number) is set to a packet transferred based on 
a specified connection ID (connection ID designated by 
the field 511). The destination node 304 can monitor 
continuity of segment data successively subjected to 
Asynchronous broadcast transaction by the sequence 
number. When an inequality occurs, the destination 
node 304 can request for resend based on the sequence 
number. 

[0291] A field 515 (16 bits) indicates 
reconfirmation_number. In the embodiment the field has 
a meaning only when the resend request flag has a val- 
ue of 1 . For example, when the value of the resend re- 



quest flag is 1 , the sequence number of the packet re- 
questing for resend is set in the field. 
[0292] A field 516 (16 bits) indicates buffer_size. The 
internal buffer size of the destination node 304 is set in 
5 the field. 

[0293] A field 1 302 (16 bits) indicates reserved, and 
is reserved for future expanding specifications. 
[0294] A field 51 9 (32 bits) indicates data_CRC : and 
error detecting codes for the fields 511 to 518 (including 

<o the header information 1 301 and the data field 524) are 
stored in the same manner as the header_CRC. 
[0295] A structure of the acknowledge packet will next 
be described. The destination node 304 having received 
the segment data by Asynchronous broadcast packet 

is shown in Fig. 13 returns a response using the acknowl- 
edge packet shown in Fig. 14. 

[0296] tn Fig. 14, afield 1401 (4 bits) is afield in which 
ack_code is stored. The aforementioned ack_busy_A, 
ack_busy_B, ack_busy_X, or another code is trans- 

20 ferred to the source node 302 by the field. 

[0297] A field 1402 (4 bits) is a field in which 
ack_parity is stored. A parity check code of the acknowl- 
edge packet is stored in the field. For example, in the 
second embodiment, a complement of a value 1 of the 

2S ack_code is stored. The field is used in error detection 
of the field 1401. 

[0298] The next field 1403 (8 bits) is a field in which 
min_retry_period is stored. The value of the minimum 
retry period shown in Figs. 10, 11 is stored in the field, 

30 for example, in units of one millisecond. For example, 
when the value of the field is 01 16 , the source node 302 
having received the acknowledge packet sets the mini- 
mum retry period to one millisecond, and operates not 
to perform retrying during the period. Additionally, the 

35 time unit which can be set in the field 1 403 is not limited 
to one millisecond, and another time unit may be used. 
[0299] Here, each destination node 304 can variably 
set an optimum value to be stored in the field 1403 in 
accordance with its reception ability or load state. For 

*o example, each destination node 304 monitors its load 
state, sets targe the value of minimum retry period when 
the load is large, and sets small the value when the load 
is small. 

[0300] For the node load state, the number of retries 
45 performed on the node, the number of packets transmit- 
ted to the node, the occupied state of the node buffer, 
the number of connections of the node, and other vari- 
ous indicators can be used. Additionally, the indicator 
for detecting the node load state is not limited as long 
so as the node load state can be detected. 

[0301] Additionally, in the embodiment, the value to 
be stored in the field 1 403 can be provided with a special 
meaning. For example, a standard (default) value is set 
as 00 16 , and the minimum retry period indicated by the 
ss value may be set to 100 milliseconds. Additionally, the 
minimum retry period indicated by the standard (default) 
value is not limited to 100 milliseconds, and another val- 
ue may be set. Moreover, for example, a so-called im- 
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mediately retry may be indicated, in which 00 16 is set as 
the standard (default) value to perform retrying as soon 
as possible. 

[0302] Fig. 15 is a diagram showing operation for set- 
ting the minimum retry period. Fig. 1 5A shows an oper- 
ation flow in which the packet is transmitted/received be- 
tween the source node 302 performing Asynchronous 
broadcast transaction and the destination node 304 re- 
turning the acknowledge packet shown in Fig. 14 to the 
transaction. Moreover, Fig. 15B is a graph showing 
changes of the load state of the destination node 304 
with time. In Fig. 15B, the load state of the destination 
node 304 is shown in a horizontal direction, while the 
elapse of time is indicated in a vertical direction. 
[0303] In Fig. 15, at a time ^ when the source node 
302 performs a first Asynchronous broadcast transac- 
tion (write request #1), the load of the destination node 
304 is relatively small L v and busy (1501 of Fig. 15). In 
this case, for example, the destination node 304 sets 
the value of the min_retry_period to 32 16 , and returns 
the acknowledge packet of ack_busy_X (1502 of Fig. 
15). 

[0304] The source node 302 sets the minimum retry 
period to 50 milliseconds from the value of the 
min_retry_period of the acknowledge packet (1503 of 
Fig. 1 5). The source node 302 performs no retry during 
the minimum retry period, and performs retrying at least 
50 milliseconds later (1504 of Fig. 15, retry #1). In Fig. 
15, the retry is successful, and the write transaction is 
completed (1505 of Fig. 15). 

[030S] Subsequently, at a time t 2 when the source 
node 302 performs a second Asynchronous broadcast 
transaction (write request #2), the load of the destination 
node 304 is relatively large Lg, and busy (1506 of Fig. 
1 5). For example, the destination node 304 sets the val- 
ue of the min_retry_period to B4 16 , and returns the ac- 
knowledge packet of ack_busy_X (1 506 of Fig. 1 5). 
[0306] The source node 302 sets the minimum retry 
period to 160 milliseconds from the value of the 
min_retry_period of the acknowledge packet (1 507 of 
Fig. 15). The source node 302 performs no retry during 
the minimum retry period, and performs retrying at least 
180 milliseconds later (1508 of Fig. 15, retry #2). 
[0307] In the aforementioned operation, in the em- 
bodiment, since the destination node to send the ac- 
knowledge packet dynamically sets the minimum retry 
period, there can be provided a communication system 
and a communication protocol, in which more secure 
data communication is assured. Additionally, even if the 
bus is congested, the busy state is prevented from oc- 
curring frequently, and the deadlock can be prevented 
from occurring. Moreover, in the aforementioned oper- 
ation, in the embodiment, since the minimum retry peri- 
od can dynamically be set, communication resource can 
appropriately be distributed, and communication effi- 
ciency can be enhanced while the communication path 
is not occupied with the source node to perform retrying. 
[0308] Moreover, in the aforementioned operation, 



even when transfer is executed between the source 
node fast in transmission speed and the destination 
node slow in reception speed, the source node can be 
prevented from frequently performing retrying, and the 
s receiving buffer of the destination node can constantly 
be prevented from becoming full. 
[0309] Additionally, in Fig. 1 5, to simplify the descrip- 
tion, transfer between one source node 302 and one 
destination node 304 is shown, but the same processing 
10 can be performed even when more than one destination 
node 304 are provided. In this case, the source node 
302 determines an optimum minimum retry period 
based on the acknowledge packet transferred from 
each destination node 304. 
is [0310] As described above, in the embodiments, the 
logical connection relationship independent of the phys- 
ical connection mode can be constructed in the bus type 
network like the IEEE 1394-1995 standards. 
[0311] Moreover, according to the embodiment, in the 
20 communication system conforming to the IEEE 
1394-1995 standards, there can be provided a com- 
pletely novel communication protocol in which a rela- 
tively large amount of object data (e.g., still image data, 
graphic data, text data, file data, program data, and the 
2S like) requiring no real-time properties but requiring reli- 
ability are segmented into one or more segment data, 
and continuously transferred. 

[0312] Furthermore, according to the embodiment, in 
the communication system conforming to the IEEE 
30 1394-1995 standards, there can be provided a com- 
pletely novel communication protocol which realizes da- 
ta communication between a plurality of apparatuses 
using a communication system to broadcast data asyn- 
chronously. 

35 [0313] Additionally, in the embodiment, a plurality of 
continuous data can securely be transferred without us- 
ing Isochronous transfer system of the IEEE 1394-1995 
standards. Moreover, one object data is segmented into 
a plurality of data, and can securely be transferred. 
40 [0314] Moreover, in the embodiment, since the com- 
munication among the plurality of apparatuses is con- 
trolled with one connection, a plurality of communica- 
tions can simultaneously be performed without using 
much communication band. 
45 [0315] Furthermore, in the embodiment, when the da- 
ta transfe r is interrupted by the bus reset or transmission 
error, it can be known which segment data is lost, and 
transfer can be resumed without following a very intri- 
cate communication procedure. 

so 

OTHER EMBODIMENT 

[0316] The communication protocol and various nec- 
essary processing operations for realizing the commu- 
55 nication protocol described in the above embodiments 
can be realized by software. 

[0317] For example, a storage medium in which a pro- 
gram code for realizing the aforementioned embodi- 
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ment function is stored Is supplied to apparatus control- 
lers constituting the communication system of the em- 
bodiment (e.g., MPU 12, system controller 50, printer 
controller 68 of Fig. 2). Subsequently, the controller 
reads the program code stored in the storage medium, 
and controls the communication system or the appara- 
tus operation to realize the embodiment function in ac- 
cordance with the program code. The aforementioned 
embodiment can thus be realized. 
[0318] Moreover, the storage medium in which the 
program code for realizing the aforementioned embod- 
iment function is stored is supplied to the 1 394 interlace 
1 4, 44, 62 mounted on each apparatus, and the control- 
ler (e.g., serial bus management 806 of Fig. 8) for con- 
trolling the operation of the 1394 interface 14, 44, 62 
controls the processing operation to realize the embod- 
iment function in accordance with the program code 
stored in the storage medium. 
[0319] In this case, the program code read from the 
storage medium realizes the embodiment function, and 
the program code and the means for supplying the pro- 
gram code to the controller (e.g., the storage medium 
itself) constitute the present invention. 
[0320] For the storage medium in which the program 
code is stored, for example, floppy disc, hard disc, op- 
tical disc, magnetic optical disc, CD-ROM, magnetic 
tape, non-volatile memory car, ROM, and the like can 
be used. 

[0321] Moreover, it goes without saying that the 
present invention also includes a case where the pro- 
gram code read from the storage medium realizes the 
embodiment functions in cooperation with OS (operat- 
ing system) operated on the controllers, various appli- 
cation software, and the like. 

[0322] The present invention further includes a case 
where after the program code read from the storage me- 
dium is stored in the memory mounted on the function 
expansion unit connected to the controller, the controller 
provided on the function expansion unit performs a part 
or whole of the actual processing in accordance with the 
program code stored in the memory to realize the em- 
bodiment functions. 

[0323] The invention may be embodied in other spe- 
cific forms without departing from the spirit or essential 
characteristics thereof. 

[0324] For example, the communication protocol of 
the first embodiment can be combined with that of the 
second embodiment. Therefore, the optimum time inter- 
val between the i-th and (i+1)-th Asynchronous broad- 
cast transactions can be determined. Additionally, even 
if the i-th Asynchronous broadcast transaction is not nor- 
mally received, retry can be inhibited for the predeter- 
mined time. 

[0325] Moreover, in the embodiments, the communi- 
cation protocol applicable to the network conforming to 
the IEEE 1 394-1 995 standards has been described, but 
the invention is not limited thereto. The communication 
protocol of the embodiment can be applied to a bus-type 



network like in the IEEE 1 394-1 995 standards or a net- 
work which can virtually constitute the bus-type network. 
[0326] Therefore, the above-mentioned embodi- 
ments are merely examples in all respects, and must 
s not be construed to limit the invention. 

[0327] The scope of the present invention is defined 
by the scope of the appended claims, and is not limited 
at all by the specific descriptions of this specification. 
Furthermore, all the modifications and changes belong- 
to ing to equivalents of the claims are considered to fall 
within the scope of the present invention. 



1. A data communication system comprising: 

a source node for performing asynchronous 
communication at least once to transfer data 

20 comprising one or more segments; 

one or more destination nodes for receiving the 
data transferred from said source node; and 
a controller for setting a logical connection re- 
lationship between said source node and said 

2S one or more destination nodes, wherein 

at least one of said source node and said con- 
troller controls a timing for performing said 
asynchronous communication. 

30 2. The data communication system according to claim 
1, wherein said source node transfers said data 
based on the logical connection relationship with 
said one or more destination nodes. 

35 3. The data communication system according to claim 
1 or 2, wherein said source node continuously per- 
forms said asynchronous communication at least 
once. 

*o 4. The data communication system according to any 
one of claims 1 to 3, wherein said one or more des- 
tination nodes receive said data based on the logi- 
cal connection relationship with said source node. 

45 5. The data communication system according to any 
one of claims 1 to 4, wherein said one or more des- 
tination nodes use said asynchronous communica- 
tion to return a response to the transferred data. 

50 6. The data communication system according to any 
one of claims 1 to 5, wherein said controller can set 
one or more logical connection relationships be- 
tween said source node and said one or more des- 
tination nodes. 



55 



7. The data communication system according to any 
one of claims 1 to 6, wherein said logical connection 
relationship is released by said controller or the des- 
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tination node after said data is transferred. 

8. The data communication system according to any 
one of claims 1 to 7, wherein at least one of said 
source node and said controller controls a period of 
time until the next asynchronous communication is 
performed. 

9. The data communication system according to any 
one of claims 1 to 7, wherein at least one of said 
source node and said controller controls a time until 
a response corresponding to said asynchronous 
communication is received. 

10. The data communication system according to any 
one of claims 1 to 9, wherein said one or more des- 
tination nodes notify at least one of said source 
node and said controller of a time interval necessary 
for receiving said asynchronous communication. 

11. The data communication system according to any 
one of claims 1 to 10, wherein said source node 
controls a time for retrying said asynchronous com- 
munication. 

12. The data communication system according to any 
one of claims 1 to 1 1 , wherein said one or more des- 
tination nodes notify said source node of a time in- 
terval necessary for retrying said asynchronous 
communication. 

13. The data communication system according to any 
one of claims 1 to 12, wherein said data communi- 
cation system performs initialization necessary for 
transferring said data between said source node 
and said one or more destination nodes. 

14. The data communication system according to claim 
13, wherein said controller can set a part of initial 
information set in said initialization. 

15. The data communication system according to claim 
13 or 14, wherein said one or more destination 
nodes notify said source node of the initial informa- 
tion necessary for said initialization. 

16. The data communication system according to any 
one of claims 13 to 15, wherein said source node 
uses the initial information notified from said one or 
more destination nodes to perform said initializa- 

17. The data communication system according to any 
one of claims 13 to 16, wherein at least one of a 
destination address for designating a memory 
space of said one or more destination nodes in com- 
mon and a receiving buffer size is set in said initial- 
ization. 
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18. The data communication system according to any 
one of claims 1 to 1 7, wherein said source node us- 
es said asynchronous communication to broadcast 
said data. 

5 

19. The data communication system according to any . 
one of claims 1 to 18, wherein said source node us- 
es said asynchronous communication to write said 
data into a common memory space of said one or 

10 more destination nodes. 

20. The data communication system according to any 
one of claims 1 to 1 9, wherein said one or more des- 
tination nodes store said data into the common 

'5 memory space of the destination nodes. 

21. The data communication system according to any 
one of claims 1 to 20, wherein said asynchronous 
communication conforms to Asynchronous transfer 

20 system of IEEE 1 394-1 995 standards. 

22. The data communication system according to any 
one of claims 1 to 21 , wherein said data communi- 
cation system is a bus-type network. 

25 

23. The data communication system according to any 
one of claims 1 to 22, wherein said data communi- 
cation system is a network conforming to the IEEE 
1394-1995 standards. 

30 

24. The data communication system according to any 
one of claims 1 to 23, wherein said data comprising 
one or more segments is at least one of still image 
data, graphic data, text data, file data, and program 

35 data. 

25. A data communication method comprising steps of: 

setting a logical connection relationship be- 
*o tween a source node and one or more destina- 

tion nodes; 

performing asynchronous communication at 
least once to transfer data comprising one or 
more segments to said one or more destination 

45 nodes; 

controlling a timing for performing said asyn- 
chronous communication; and 
using said logical connection relationship to re- 
ceive the data transferred using said asynchro- 

so nous communication. 

26. A data communication system comprising; 

a source node for performing broadcast com- 
55 munication at least once to transfer data com- 

prising one or more segments based on a log- 
ical connection relationship; and 
one or more destination nodes for receiving the 
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data transferred from said source node based 
on said logical connection relationship, wherein 
said source node controls a timing for perform- 
ing said broadcast communication. 

s 

27. A data communication method comprising steps of: 

performing broadcast communication at least 
once to transfer data comprising one or more 
segments to one or more destination nodes '0 
based on a logical connection relationship; 
controlling a timing for performing said broad- 
cast communication; and 
receiving the data transferred from said source 
node based on said logical connection relation- is 
ship. 

28. A data communication apparatus comprising; 

means for packetizing data comprising one or 20 
more segments into a plurality of communica- 
tion packets; and 

means for successively transferring the com- 
munication packets based on a logical connec- 
tion relationship set with one or more destina- zs 
tion nodes, wherein 

the communication packets are asynchronous- 
ly transferred after a predetermined time elaps- 
es. 

30 

29. The data communication apparatus according to 
claim 28, wherein the communication packets are 
retried after the predetermined time elapses. 

30. A data communication method comprising steps of: 3S 

packetizing data comprising one or more seg- 
ments into a plurality of communication pack- 
ets; and 

successively transferring the communication 40 
packets based on a logical connection relation- 
ship set with one or more destination nodes, the 
communication packets being asynchronously 
transferred after a predetermined time elapses. 

45 

31 . The data communication method according to claim 
30, further comprising step of: 

retrying the communication packets after the 
predetermined time elapses. so 

32. A data communication apparatus comprising: 

means for receiving communication packets 
successively transferred from a source node ss 
based on a logical connection relationship set 
with the source node; and 
means for writing data included in said commu- 



nication packets into a memory space common 
to other apparatuses, wherein 
the communication packets are asynchronous- 
ly transferred after a predetermined time elaps- 



33. A data communication method comprising steps of: 

receiving communication packets successively 
transferred from a source node based on a log- 
ical connection relationship set with the source 
node, the communication packets being asyn- 
chronously transferred after a predetermined 
time elapses; and 

writing data included in said communication 
packets into a memory space common to other 
apparatuses. 

34. A data communication apparatus comprising: 

means for setting a logical connection relation- 
ship between a source node and one or more 
destination nodes and for setting in the source 
node a time interval of communication packets 
successively transferred based on the logical 
connection relationship; and 
means tor notifying said source node and said 
one or more destination nodes of a connection 
ID for identifying said logical connection rela- 
tionship. 

35. A data communication method comprising steps of: 

setting a logical connection relationship be- 
tween a source node and one or more destina- 
tion nodes; 

notifying said source node and said one or 
more destination nodes of a connection ID for 
identifying said logical connection relationship; 
and 

setting in said source node a time interval of 
communication packets successively trans- 
ferred based on said logical connection rela- 
tionship. 

36. A digital interface comprising: 

means for packetizing data comprising one or 
more segments into a plurality of communica- 
tion packets; and 

means for successively transferring the com- 
munication packets based on a logical connec- 
tion relationship set with one or more destina- 
tion nodes, wherein 

the communication packets are asynchronous- 
ly transferred after a predetermined time elaps- 
es. 
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37. A digital interlace comprising: 

means for receiving communication packets 
successively transferred from a source node 
based on a logical connection relationship set s 
with the source node; and 
means for writing data included in said commu- 
nication packets into a memory space common 
to other apparatuses, wherein 
Ihe communication packets are asynchronous- »o 
ly transferred after a predetermined time elaps- 
es. 

38. A digital interface comprising: 

(5 

means for setting a logical connection relation- 
ship between a source node and one or more 
destination nodes and for setting in the source 
node a time interval of communication packets 
successively transferred based on the logical 20 
connection relationship; and 
means for notifying said source node and said 
one or more destination nodes of a connection 
ID for identifying said logical connection rela- 
tionship. 25 
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